home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄19⁄90 / 0425-Design the Guerilla-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  6.1 KB  |  129 lines  |  [TEXT/GEOL]
  1. Item    4893728                         15-Jan-90        14:13
  2.  
  3. From:   D5295                           Reseach SW Design, D Goldman,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. cc:     SOFTARCH                        SW Architects, Carl Nelson,PRT
  8.  
  9. Sub:    Design the Guerilla
  10.  
  11. Here's how I currently envision the pan-galactic voluntarily-developed-and-
  12. maintained supplemental MacApp class library. (The name could be a bit more
  13. concise -- see accompanying "Name the Guerilla" memo.)
  14.  
  15. The library will have a folder of its own within, presumably, the MacApp
  16. Discussion folder. The folder will be a one-way bulletin board, to which only
  17. the overall coordinator (me) can post memos. There will be an "About this BB"
  18. memo explaining the way this all works. (Hmm… you may be reading the first
  19. draft of that memo right now.)
  20.  
  21. Then there will be a "Table of Contents" memo. This memo will list, for each
  22. project, the following info:
  23.  
  24.          -- name of project
  25.          -- description (1-2 sentences) of project
  26.          -- project coordinator's name, affiliation, and AppleLink address
  27.          -- current status
  28.  
  29. For example:
  30.  
  31.    FullTEView
  32.          A subclass of TTEView which implements the full Apple Human
  33.             Interface Guidelines, including intelligent cut & paste, use
  34.             of shift, option, and command keys with the arrow keys, intel-
  35.             ligent definition of "word" for double-clicking, etc.
  36.  
  37.          Dave Goldman, Research Software Design, AppleLink: D5295
  38.          Initial draft posted 1/29/90; soliciting review and suggestions.
  39.  
  40. If you were interested in looking at or using the current version of this
  41. project, you would then download the memo called "FullTEView" (or
  42. "FullTEView.sit", as the case may be), which will contain the actual code and
  43. documentation. If you then had any comments on the project, you would address
  44. them to the project's coordinator.
  45.  
  46. If you would like to help polish the project, you'd send a link to the
  47. project's coordinator indicating your interest. The project coordinator will
  48. add your name to his/her personal mailing list, and inform others already on
  49. the list of your existence.
  50.  
  51. Project members will pass ideas and drafts of code and documentation back and
  52. forth via AppleLink mail. At any time the project coordinator can send the
  53. overall coordinator (me) an updated copy of the project to be posted on the
  54. bulletin board, replacing the previous copy. I will update the Table of
  55. Contents Memo accordingly.
  56.  
  57. If a project coordinator gets tired of the role, he/she should try to find
  58. someone else to take it on. Failing that, the Table of Contents will list the
  59. project as "orphaned." An orphaned project remains posted on the bulletin
  60. board. It may subsequently be "adopted" by anyone who wants to take it over.
  61. (If the adopter has massive changes in mind, though, it would be more
  62. appropriate to start a new project, such as "FullerTEView".)
  63.  
  64. To start a new project, you would send the overall coordinator a link
  65. containing the same information that goes in the Table of Contents. If it
  66. sounds a lot like an existing project, I'll put you in touch with that
  67. project's coordinator. Otherwise I'll add your entry to the Table of Contents
  68. and post any code or documentation which you may already have.
  69.  
  70. You can start a project even if you haven't yet written any of it. For example,
  71. the status line of the above Table of Contents entry could have read:
  72.  
  73.          Looking for other volunteers to help design this from the ground up.
  74.  
  75. or whatever.
  76.  
  77. It would be very nice to have "final" drafts of projects reviewed by someone at
  78. Apple. Keith Stattenfield has already volunteered to help. It would be great if
  79. someone from the MacApp development group could also offer a "stamp of
  80. approval." (An Apple symbol next to the status line…?)
  81.  
  82. All posted projects would be public domain, with no warranties of any kind. It
  83. will be the responsibility of anyone downloading any of this code to
  84. periodically check for him/herself whether the project has since been updated.
  85.  
  86. If the MacApp development team wants to incorporate any or all of a project
  87. into a future release of MacApp, that will be fine. (I'll leave the details of
  88. MacApp™ copyright notices to Apple's lawyers.)
  89.  
  90. The projects may be copied at any time to MADA's own bulletin board, MADA
  91. "Goodies" disks, and other BB's (Compuserve, bix, BITNET, whatever). Probably
  92. only "final" drafts should be copied in most cases.
  93.  
  94. I see my role of overall coordinator as rather limited. It will be my job to
  95. try to prevent duplicate or heavily-overlapping projects. I will keep the Table
  96. of Contents up to date, and the bulletin board navigable. In no way will I edit
  97. (or even, in lots of cases, look at) the posted projects -- that's the
  98. responsibility of the individual project coordinators.
  99.  
  100. I may occasionally solicit contributions. For example, if somebody has put code
  101. up on MacApp.Tech$ which looks useful (such as the three Windows menu recipes
  102. in the recent FrameWorks), I might ask them if they'd be willing to post it as
  103. a project. Of course, *anybody* could suggest that to them.
  104.  
  105. But in general this will be a bottom-up development effort. It will not be my
  106. job to decide which projects are "worth" posting -- if you want to coordinate
  107. something, you're in.
  108.  
  109. A couple of other issues remain…
  110.  
  111. DOCUMENTATION: I envision most of these projects as small enough to make
  112. on-line documentation the best approach. Many of them should be adequately
  113. documented if they have medium-extensive comments at the top of the code. Those
  114. which are more complex could have a separate text file of explanatory material.
  115.  
  116. INCENTIVES: Carl Nelson has suggested MADA's willingness to provide
  117. "incentives" for participation. Those involved in a completed project could
  118. receive appropriately-inscribed T-shirts, mugs, pens, etc. Personally, though,
  119. I've already got plenty of those things littering my office and home. Maybe
  120. participants could receive a credit to their AppleLink account?
  121.  
  122.  
  123. None of this is final. Please send me your suggestions. (Send them to D5295,
  124. with optional copy to MacApp.Tech$)
  125.  
  126. -- Dave Goldman, D5295
  127.    Research Software Design
  128.  
  129.